-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interactive namespace selection #1285
base: main
Are you sure you want to change the base?
Interactive namespace selection #1285
Conversation
…e-merge-main Merge main into feature/serverless
…alocean#1232) * Add support for triggers * Add lastRun field to trigger list output * Hide commands we won't be supporting in EA day 1 * Bump deployer version to pick up bug fix * Fix error handling in services related to triggers Many calls were not checking for errors. * Switch to latest API Change both the triggers command (native to doctl) and the deployer version (which affects the semantics of deploy/undeploy). * Pick up latest deployer (triggers bug fix) * Remove support for prototype API and clean up code * Fix unit tests * Fix misleading comment * Remove added complexity due to successive change * Add filtering by function when listing triggers * Fix omitted code in DeleteTrigger * Guard triggers get/list with status check Otherwise, the credentials read fails with a cryptic error instead of an informative one when you are not connected to a namespace.
…-main Merge latest `main` changes into `feature/serverless`
This completes the elimination of plugin usage in doctl sls fn and the functions.go source file.
I believe this happened in merge conflict resolution during the recent rebase.
Affects what happens when a failure occurs in the middle of deleting functions and triggers together.
…on-list-no-plugin Finish eliminating plugin usage in 'doctl sls functions' + testing improvements
…#1270) * WIP for converting activations to direct OW flows * Finish recoding 'activations get' in native doctl Tests still to come * Convert the support for sls actv result Tests not converted yet * Generate latet mocks * Fix some comments * Use more realistic timestampes * Revise tests for new paths. Still no output check * Tests are now doing meaningful output comparison Fixed some bugs found once tests were really effective
Re-writes activations list command subtree in Go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice one Davi!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't reviewed the code in detail but I want to raise a fundamental problem with the change. I tried it out, and it behaves nicely when I run it in a true terminal window. However, when I run it in an emacs shell (which is not a full-fledged terminal), or even in emacs term
(which is more like a real terminal but with some emacs intermediation) the results are confusing.
In emacs shell, when selection from a prompt is required due to multiple namespace matches: things spew on the window and an informed selection is impossible. I'm not even going to try to show it here.
In emacs shall, when prompting is not required (an unambiguous namespace hint is provided), the experience is better but the "spinner" messages are annoying and keep the final message from being read easily:
ds connect lon
⣽ Loading namespaces ...⣻ Loading namespaces ...⢿ Loading namespaces ...⡿ Loading namespaces ...⣟ Loading namespaces ...⣯ Loading namespaces ...⣷ Loading namespaces ...⣾ Loading namespaces ...⣽ Loading namespaces ...⣻ Loading namespaces ...⢿ Loading namespaces ...Connected to functions namespace '<redacted>' on API host '<redacted>' (label=london)
In emacs term
when a sufficient hint is provided, the result is satisfactory.
In emacs term
when there is actual prompting, the prompt is impossible to use effectively because the cursor movements don't work as they would on a regular terminal (this might depend on emacs key bindings, not sure).
General points:
- the spinner is IMO unnecessary and less is more there
- the new prompt logic is nice to look at and might be fine in a full function terminal window but what was there before was good enough and by virtue of being minimal was more likely to work in more environments.
I'd be comfortable approving this iff the spinner was dropped and the improved selection experience were somehow guarded by a solid test for being in a real terminal. When the terminal is not "real", there should be a fallback to the simpler logic.
…eractive-namespace-selection
I updated the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried out the latest version of this in emacs shell. Result:
Error: Namespace is required when running non-interactively
This is a regression in terms of UX. Before the change, I would have gotten the simple plain-text prompt. I am actually running interactively, albeit in a less than fully functional terminal. I was assuming that, when a deficient terminal is detected, the behavior would revert to limited plain text interactivity. This is what commands like man
do.
I also tried this in emacs term
(I don't generally use that but others undoubtedly do and it is often given as the solution when people find that things they want to use don't work in emacs shell
). The behavior there is unchanged from before the latest change: the behavior is "interactive" but it is difficult and counterintuitive to read the prompts and make a selection due to the way the text is formatted. IMO the plain text solution would be better there as well.
I don't want to stand in the way of more interactivity in doctl
(a good thing) and more use of state-of-the-art interaction paradigms, text coloring, etc. on real terminals (a good thing) but I feel our interactivity framework and practices must take into account that there are interactive environments that are not terminals and allow users who use those environments to have an acceptable and non-frustrating experience.
Thank you for the PR @ddebarros and thank you for the feedback @joshuaauerbachwatson. This PR opens up a larger question of how and if Doctl stays up to date with new UI CLI methodologies. At the same time, we cannot allow any breaking changes to Doctl that might increase churn or loss of revenue. Doctl runs on an unknown amount of systems, shells, and environments. With the current priorities of the company and team, we will have to revisit Doctl UI updates. This is a great starting point @ddebarros and I look to merging this and similar PRs in the future. For today and for the foreseeable future, we will leave this PR open and unmerged. |
Screen.Recording.2022-10-18.at.11.40.03.AM.mov